IRS-III: A broker-based approach to semantic Web services

objects, characterized by a signature, comprised of universes, functions, and relations. The universe or domain is a set of data containing partial functions and predicates (attributes and relations) which encapsulate the universe. Transition rules, in ASMs, are local functions which update the abstract states, and can be expressed as follows: f(t1, t2, ..., tn):= t where f is an n-ary function, t is a function name, and t1, t2,.., tn are terms. In our interface model, given a transition step Ti, a state si ∈ S is a non-empty set of ontologies that define a state signature over which transition rules are executed. Optional mediators are used to solve ontology or data mismatches. The parameterized choreography state is a set of instances, concerning message exchange patterns and the choreography execution. Every state includes a constant subset, which identifies the Web service host, port, and location, which is invariant whenever the same Web service is invoked, and the event instantiation e ∈ Ec, dependent on the event which occurred at step Ti. The orchestration states characterize the phases of the workflow process during goal composition. Given a transition step Ti, an orchestration state contains a description of the triggering-event, the control flow step identifier, and the result the output of the achieved sub-goal. A condition c ∈ C (also called guard) depicts a situation occurring during interface execution. Every constraint within the condition has to be verified before the next event is triggered. Transition rules express changes of state by modifying a set of instances within the state signature. In particular, a transition rule, t ∈ T, updates the state after the occurrence of an event, e ∈ E, and consists of a function, ( ) S S t E C → 2 , : , that associates a pair (s, {c1, .., cn}) to s’, where s and s’ ∈ S, and every ci ∈ C (1 ≤ i ≤ n) . 5.2 Choreography Implementation Choreography addresses the problem of communication between a client and a Web service. Since the IRS-III acts as a broker the focus of our choreography work is between the IRS-III and the relevant deployed Web services. We assume that IRS-III clients are able to formulate their request as a goal instance. This means that we only require choreographies between the IRS-III and the deployed Web services. Our choreography descriptions are therefore written from the perspective of the IRS-III as a client of the Web service. A choreography is described in IRS-III by the declaration of a grounding and a set of guarded transitions. The grounding specifies the conceptual representation of the operations involved in the invocation of a Web service and their mapping to the implementation level. More specifically, the grounding definitions include operation-name, input-roles-soap-binding, and output-rolesoap-binding. Guarded transitions can be seen as ASM transition rules as above with two specific restrictions: a) ‘If’ rules do not chain and are of the form “If condition then Fire Event”; and b) conditions are mutually exclusive so only one rule can fire at a time. These represent the interaction between IRS-III and the Web service and are applied when executing the choreography. This model is executed at a semantic level when IRS-III receives a request to achieve a goal. Our overall view is that any message sent by IRS-III to a Web service will depend on its current state, which will include a representation of the messages received during the current conversation. As mentioned earlier we classify communication in IRS-III choreography according to two dimensions, following the system-client cooperation model proposed in KADS [De Greef and Breuker, 1992], namely: 1) the initiative in the communication; and 2) the direction of the communication [Galizia and Domingue, 2004]. The initiative dimension expresses which actor, either the